X10 is an advanced object-oriented language with a complex type-system
    and concurrency constructs.
This section describes how object initialization interacts with X10 features.
We begin with object-oriented features found in mainstream languages,
    such as constructors, inheritance, dynamic dispatch, exceptions, and inner classes.
We then proceed to X10's type-system features,
    such as constraints, properties, class invariants, closures, (non-erased) generics, and structs,
followed by the parallel features of X10 for writing concurrent code (\code{finish} and \code{async}),
    and distributed code (\code{at}\removeGlobalRef{ and global references}).
Finally, we describe the inter-procedural data-flow analysis that ensures that
    a field is read only after it has been assigned.
%Finally, we summarize the virtues and attributes of initialization in X10.


\subsection{Constructors and inheritance}
Inheritance is the first feature that interacts with initialization:
    when class \code{B} inherits from \code{A}
    then every instance of \code{B} has a sub-object that is like an instance of \code{A}.
When we initialize an instance of \code{B}, we must first initialize its \code{A} sub-object.
We do this in X10 by forcing the constructors of \code{B} to make a super call,
    i.e., call a constructor of \code{A}
    (either explicitly or implicitly).



\begin{figure}
\definerule{Rule3}
\definerule{Rule4}
\definerule{Rule5}
\definerule{Rule6}

\vspace*{-3.0ex}
\subfloat[Escaping \this example]{\lstinputlisting[boxpos=t]{Escaping-this.txt}}
~~
\subfloat[Dynamic dispatch example]{\lstinputlisting[boxpos=t]{Dynamic-dispatch.txt}}
\vspace*{-1.0ex}

\caption{\textbf{Definition of \emph{raw}:}
    {\this and \code{super} are \emph{raw} in {non-escaping} methods and in field initializers}.
    \textbf{Definition of \emph{non-escaping}:}
        {A method is \emph{non-escaping} if it is a constructor,
            or annotated with \code{@NonEscaping} or \code{@NoThisAccess},
            or a method that is called on a raw \this receiver}.
    \myrule{\arabic{Rule3}}{A raw \this or \code{super} cannot escape or be aliased}
    \myrule{\arabic{Rule4}}{A call on a raw \code{super} is allowed only for a \code{@NonEscaping} method}
    \myrule{\arabic{Rule5}}{A non-escaping method must be private or final, unless it has \code{@NoThisAccess}}
    \myrule{\arabic{Rule6}}{A method with \code{@NoThisAccess} cannot access \this or \code{super} (neither read nor write its fields)}
    }
\label{Figure:Escaping-this}
\end{figure}




\Ref{Figure}{Escaping-this} shows X10 code that demonstrates the interaction
    between inheritance and initialization,
    and explains by example why leaking \this during construction can cause bugs.
In all the examples, all errors issued by the X10 compiler are marked with \code{//err}
    (and if there is no such mark then the code is correct).

We say that an object is \emph{raw} (also called partially initialized) before its constructor ends,
    and afterward it is \emph{cooked} (also called fully initialized).
Note that when an object is cooked, all its sub-objects must be cooked as well.
X10 prohibits any aliasing or leaking of \this during construction,
    therefore only \this or \code{super} can be raw (any other variable is definitely cooked).

Object initialization begins by invoking a constructor,
    denoted by the method definition \code{def this()}.
The first leak would cause a problem because field \code{a} was not assigned yet.
However, even after all the fields of \code{A} have been assigned,
    leaking is still a problem
    because fields in a subclass (field \code{b}) have not yet been initialized.
Note that leaking is not a problem if \this is not raw, e.g., in \code{m1()}.

We begin with two definitions:
    (i)~when an object is \emph{raw}, and
    (ii)~when a method is \emph{non-escaping}.
(i)~Variables \this and \code{super} are raw
    during the object's construction,
    i.e., in field initializers and in {non-escaping} methods
    (methods that cannot escape or leak \this).
(ii)~Obviously constructors are non-escaping,
    but you can also annotate methods \emph{explicitly} as \code{@NonEscaping},
    or they can be inferred to be \emph{implicitly} non-escaping
    if they are called on a raw \this receiver.

For example, \code{m2} is \emph{implicitly} non-escaping (and therefore cannot leak \this)
    because of the call to \code{m2}
    in the constructor.
The user could also mark \code{m2} \emph{explicitly} as non-escaping by using the annotation
    \code{@NonEscaping}.
(Like in Java, \code{@} is used for annotations in X10.)
We recommend explicitly marking non-escaping methods as \code{@NonEscaping} to show intent,
    as done on method \code{m3}.
Without this annotation the call \code{super.m3()} in \code{B} would be illegal,
    due to rule~\userule{Rule4}.
(We could infer that \code{m3} must be non-escaping,
    but that would cause a dependency from a subclass to a superclass,
    which is not natural for people used to separate compilation.)
Finally, we note that all errors in this example are due to rule~\userule{Rule3}
    that prevents leaking a raw \this or \code{super}.




\subsection{Dynamic dispatch}
Dynamic dispatch may transfer control to the subclass
    before the superclass completed its initialization.
\Ref{Figure}{Escaping-this}b demonstrates why dynamic dispatch is error-prone during construction:
    calling \code{m1} in \code{A} would dynamically dispatch
    to the implementation in \code{B}
    that would read the default value.




X10 prevents dynamic dispatch by requiring that non-escaping methods
    must be private or final
    (so overriding is impossible).
For example, \code{\itshape err1} is caused by rule~\userule{Rule5}
    because \code{m1} is neither private nor final nor \code{@NoThisAccess}.

However, sometimes dynamic dispatch is required during construction.
For example, if a subclass needs to refine initialization
    of the superclass's fields.
Such refinement cannot have any access to \this, and therefore
    such methods must be marked with \code{@NoThisAccess}.
For example, \code{\itshape err2} and \code{\itshape err3} are caused by rule~\userule{Rule6} that prohibits access \this or \code{super}
    when using \code{@NoThisAccess}.
\code{@NoThisAccess} prohibits any access to \this,
    however, one could still access the method parameters.
(If the subclass needs to read a certain field of the superclass that was previously assigned,
    then that field can be passed as an argument.) % to the \code{@NoThisAccess} method


In C++, the call to \code{m1} is legal,
    but at runtime
    methods are statically bound,
    so you will get a crash trying to call a pure virtual function.
In Java, the call to \code{m1} is also legal,
    but at runtime
    methods are dynamically bound,
    so the implementation of \code{m1} in \code{B}
    will read the default values of \code{a1} and \code{b}.
%This behavior is undesired in Java,
%    and Java discourages it by trying to catch statically most of these cases.
%For example, Java prohibits calls to member functions before the super object was initialized,
%    as this example shows (which is also illegal in X10):
%\begin{lstlisting}
%class B extends A { B() {super(f()); }}
%\end{lstlisting}




\subsection{Exceptions}
Constructing an object may not always end normally,
    e.g., building a date object from an illegal date string should throw an exception.
Exceptions combined with inheritance interact with initialization in the following way:
    a cooked object must have cooked sub-objects,
    therefore if a constructor ends normally (thus returning a cooked object)
    then all preceding constructor calls (either \code{super(\ldots)} or \code{this(\ldots)})
    must end normally as well.
Phrased differently, in a constructor it should not be possible to
    recover from an exception thrown by a this or super constructor call.
This is one of the reasons why a constructor call must be the first statement in Java;
    failure to verify this led to a famous security attack~\cite{Dean:1996}.

\begin{figure}
\vspace*{-4.5ex}
\begin{lstlisting}
class B extends A {
  def this() {
    try { super(); } catch(e:Throwable){} //err
  }
}
\end{lstlisting}
\vspace*{-3.5ex}
\definerule{Rule7}
\caption{Exceptions example:
    if a constructor ends normally (without throwing an exception),
        then all preceding constructor calls ended normally as well.
    \myrule{\arabic{Rule7}}{If a constructor does not call \code{super(\ldots)} or \code{this(\ldots)},
        then an implicit \code{super()} is added at the beginning of the constructor;
        the first statement in a constructor is a constructor call (either \code{super(\ldots)} or \code{this(\ldots)});
        a constructor call may only appear as the first statement in a constructor
        }
    }
\label{Figure:Exceptions}
\end{figure}
\vspace*{-3.5ex}


\Ref{Figure}{Exceptions} shows that it is an error to try to recover from an exception thrown
    by a constructor call;
    the reason for the error is rule~\userule{Rule7} that requires the first statement to be \code{super()}.


\Subsection[Inner]{Inner classes}
Inner classes usually read the outer instance's fields during construction,
    e.g., a list iterator would read the list's header node.
Therefore, X10 requires that the outer instance is cooked,
    and prohibits creating an inner instance when the receiver is a raw \this.


\begin{figure}
\definerule{Rule8}
\definerule{Rule10}

\vspace*{-5.0ex}
\subfloat[Inner class example: the outer instance is always cooked.]{\lstinputlisting[boxpos=t]{InnerClass.txt}}
\quad
\subfloat[Default value example.]{\lstinputlisting[boxpos=t]{Constraints.txt}}
\vspace*{-2.0ex}

\caption{
    \myrule{\arabic{Rule8}}{a raw \this cannot be the receiver of \code{new}}\\
    \textbf{Definition of \emph{has-zero}:}
        {A type \emph{has-zero} if it contains the zero value
            (which is either \code{null}, \code{false}, 0, or
                zero in all fields for user-defined structs)
            or if it is a type parameter guarded with \code{haszero} (see \Ref{Section}{Generics-and-Structs}).}
    \myrule{\arabic{Rule10}}{A \code{var} field that lacks a field initializer and whose type has-zero,
        is implicitly given a zero initializer}
    }
\label{Figure:InnerClass}
\end{figure}



\Ref{Figure}{InnerClass}a shows it is an error in X10 to create an inner instance
    if the outer is raw (from rule~\userule{Rule8}),
    but it is ok to create an instance of a static nested class,
    because it has no outer instance.

In fact, it is possible to view this rule as a special case to the rule that
    prohibits leaking a raw \this
    (because when you create an inner instance on a raw \this receiver,
    you create an alias of \this,
    and now you have two raw objects: \code{Inner.this} and \code{Outer.this}).
We wish to keep the invariant that only one \this can be raw.

%To reduce complexity in the following subsections,
In our rules, we assume that there is a single \this reference,
    because we can convert all inner, anonymous and local classes into
    static nested classes
    by passing the outer instance and all other captured variables
    explicitly as arguments to the constructor.






We now turn our attention to X10's sophisticated type-system
    features not found in mainstream languages:
    constraints, properties, class invariants, closures, (non-erased) generics, and structs.

\subsection{Constraints and default/zero values}
X10 supports constrained types using the syntax \code{T\lb{}c\rb},
    where \code{c} is a boolean expression that can use final variables in scope,
    literals, properties (described below),
    the special keyword \code{self}
    that denotes the type itself,
    field access, equality (\code{==}) and disequality (\code{!=}).
There are plans to add arithmetic inequality (\code{<}, \code{<=})
    to X10 in the future,
    and one can plug in any constraint solver into the~X10~compiler.

As a consequence of constrained types,
    some types do not have a default value, e.g., \code{Int\lb self!=0\rb}.
Therefore, in X10, the fields of an object cannot be zero-initialized as done in Java.
Furthermore, in Java, a non-final field does not have to be assigned in a constructor
    because it is assumed to have an implicit zero initializer.
X10 follows the same principle, and a non-final field is implicitly given a zero initializer
    \emph{if its type has-zero}.
\Ref{Figure}{InnerClass}b defines when a type \emph{has-zero},
    and gives examples of types without zero.
Note that \code{i0} has to be assigned because it is a final field (\code{val}),
    as opposed to \code{i1} which is non-final (\code{var}).



\subsection{Properties and the class invariant}
Properties are final fields that can be used in constraints,
    e.g., \code{Array} has a \code{size} property,
    so an array of size 2 can be expressed as: \code{Array\lb self.size==2\rb}.
The differences between a property and a final field are both syntactic and semantic,
    as seen in class \code{E} of \Ref{Figure}{Properties}.
Syntactically, properties are defined after the class name,
    must have a type and cannot have an initializer,
    and must be initialized in a constructor using a property call statement written as \code{property(\ldots)}.
Semantically, properties are initialized before all other fields,
    and they can be used in constraints with the prefix \code{self}.


\begin{figure}
\vspace*{-3.5ex}
\begin{lstlisting}
class E(a:Int) {          class F(b:Int) {b==a} extends E {
  def this(x:Int) {         val f1 = a+b, f2:Int, f3:E{this.a==self.a};
       property(x);         def this(x:Int) {
  }                           super(x);
}                             val i1 = super.a;
                              val i2 = this.b; //err
                              val i3 = this.f1; //err
                              f2 = 2; //err (must be after property(x))
                              property(x);
                              f3 = new E(this.a);
                            }
                          }
\end{lstlisting}
\vspace*{-3.5ex}
\definerule{Rule17}
\definerule{Rule18}
\definerule{Rule19}
\caption{Properties and class invariant example:
        properties (\code{a} and \code{b})
        are final fields that are initialized before all other fields
        using a property call (\code{property(\ldots);} statement).
    {If a class does not define any properties, then
        an implicit \code{property()} is added
        after the (implicit or explicit) \code{super(\ldots)}.}
    {Field initializers are executed in their declaration order
        after the (implicit or explicit) property call.}
    \myrule{\arabic{Rule17}}{If a constructor does not call \code{this(\ldots)},
        then it must have exactly one
        property call, and it must be unconditionally executed
        (unless the constructor throws an exception)}
    \myrule{\arabic{Rule18}}{The class invariant must be satisfied after the property call}
    \myrule{\arabic{Rule19}}{The super fields can only be accessed after \code{super(\ldots)},
        and the fields of \this can only be accessed after \code{property(\ldots)}}
    }
\label{Figure:Properties}
\end{figure}


When using the prefix \this, you can access both properties and other final fields.
The difference between \this and \code{self} is
    shown in field \code{f3} in \Ref{Figure}{Properties}:
    \code{this.a} refers to the property \code{a} stored in \this,
    whereas \code{self.a} refers to \code{a} stored in the object to which \code{f3} refers.
(In the constructor, we indeed see that we assign to \code{f3} a new instance of \code{E}
    whose \code{a} property is equal to \code{this.a}.)

% Should I talk about interface and abstract property methods? Doesn't relate to initialization...

Properties must be initialized before other fields because
    field initializers and field types can refer to properties (see initializer for \code{f1} and the type of \code{f3}).
The superclass's fields can be accessed after the super call,
    and the other fields after the property call;
    field initializers are executed after the property call.

The \emph{class invariant} (\code{\lb{}b==a\rb} in \Ref{Figure}{Properties})
    may refer only to properties,
    and it must be satisfied after the property call (rule~\userule{Rule18}).



\subsection{Closures}
Closures are functions that can refer to final variables in the enclosing scope,
    e.g., they can refer to final method parameters, locals, and \this.
When a closure refers to a variable, we say that the variable is \emph{captured} by the closure,
    and the variable is thus stored in the closure object.
Closures interact with initialization when they capture \this during construction.

\begin{figure}
\definerule{Rule20}
\definerule{Rule21}

\vspace*{-3.0ex}
\subfloat[Closures example.]{\lstinputlisting[boxpos=t]{Closures.txt}}
\quad~~
\subfloat[\code{haszero} type predicate example.]{\lstinputlisting[boxpos=t]{Generics.txt}}
\vspace*{-2.0ex}

\caption{
    \myrule{\arabic{Rule20}}{A closure cannot capture a raw \this}\\
    \myrule{\arabic{Rule21}}{A type must be consistent, i.e., it cannot contradict method guards or class invariants}
    }
\label{Figure:Closures}
\end{figure}





\Ref{Figure}{Closures}a shows why it is prohibited to capture a raw \this in a closure:
    that closure can later escape to another place which will serialize all captured variables
    (including the raw \this, which should not be serialized, see \Ref{Section}{Multiple-Places}).
The work-around for using a field in a closure is to define a local that will refer only to the field (which is definitely cooked)
    and capture the local instead of the field as done in \code{closure2}.



\subsection{Generics and Structs}
\label{Section:Generics-and-Structs}
\emph{Structs} in X10 are header-less inlinable objects
    that cannot inherit code (i.e., they can \emph{implement} interfaces, but cannot \emph{extend} anything).
Therefore an instance of a struct type has a known size and can be inlined in a containing object.
Java's primitive types (\code{int}, \code{byte}, etc) are represented as structs in X10.
Structs, as opposed to classes, do not contain the value \code{null}.

\emph{Generics} in X10 are reified, i.e, not erased as in Java.
For example, a \code{Box[T]} has a single field of type \code{T},
    and instances of \code{Box[Byte]} and \code{Box[Double]}
    have the same size in Java but different sizes in X10.
%an instance of type \code{Box[Byte]} would have a different size than one of type \code{Box[Byte]}
Although generics are not a new concept,
    the combination of generics and the lack of default values
    leads to new pitfalls.
For example, in Java and C\#, it is possible to define an equivalent to

~~~~~~~\code{class A[T] \lb{} var a:T; \rb}\\
However, this is illegal in X10 because we cannot be sure that \code{T} has-zero (see \Ref{Figure}{InnerClass}b),
    e.g., if the user instantiates \code{A[Int\lb{}self!=0\rb]} then field \code{a} cannot be assigned a zero value
    without violating type-safety.
Therefore X10 has a type predicate written \code{X haszero} that evaluates to true if type \code{X} has-zero.
Using \code{haszero} in a constraint (e.g., in a class invariant or a method guard),
    makes it possible to guarantee that a type-parameter will be instantiated with a type that has-zero.



\Ref{Figure}{Closures}b shows an example of a generic class \code{B[T]}
    that constrains the type-parameter \code{T} to always have a zero value.
According to rule~\userule{Rule10}, field \code{f1} has an implicit zero field initializer.
It is also possible to write the initializer explicitly (as done in field \code{f2}) by using the static method \code{Zero.get[X]()}
    (that is guarded by \code{X haszero}).
Next we see two struct definitions:
    the first has two properties that has-zero,
    and the second has a property that does not have zero.
According to the definition of has-zero in \Ref{Figure}{InnerClass}b,
    a struct has-zero if all its fields has-zero,
    therefore \code{WithZeroValue haszero} is true, but
    \code{NoZeroValue haszero} is false.
Finally, we see an example of usages of \code{B[T]},
    where two usages are legal and two are illegal
    (see rule~\userule{Rule21}).







We now turn our attention to the parallel features of X10 for
    concurrent programming (\code{finish} and \code{async})
    and distributed programming (\code{at}\removeGlobalRef{ and global references}).
\Ref{Section}{Parallelism} already explained how parallel code is written in X10,
    and what are the common pitfalls of initialization in parallel code.
Next we present the rules that prevent these pitfalls.

\vspace*{-1.0ex}
\subsection{Concurrent programming and Initialization}


\begin{figure}
\definerule{Rule13}
\definerule{Rule13a}
\definerule{Rule14}

\vspace*{-3.0ex}
\subfloat[Concurrency in initialization example: asynchronously assign to a field.]{\lstinputlisting[boxpos=t]{Asynchronously-init.txt}}
\quad~
\subfloat[Distributed initialization example.]{\lstinputlisting[boxpos=t]{Multi-place.txt}}
\vspace*{-2.0ex}

\caption{
    \myrule{\arabic{Rule13}}{A constructor must finish assigning to all fields at least once}
    \myrule{\arabic{Rule13a}}{A final field can be assigned at most once}\\
    \myrule{\arabic{Rule14}}{a raw \this cannot be captured by an \code{at}}
    %\myrule{\arabic{Rule13}}{All field assignments must finish when the constructor ends}
    }
\label{Figure:Asynchronously-init}
\end{figure}
\vspace*{-1.0ex}



\Ref{Figure}{Asynchronously-init}a shows how to asynchronously assign to fields.
Recall that we wish to guarantee that one can never read an uninitialized field,
    therefore rule~\userule{Rule13} ensures that all fields are assigned at least once.

All three fields in \code{A} are asynchronously assigned,
    however, only \code{f2} is not definitely assigned at the end of the constructor.
Assigning to \code{f3} has an enclosing \code{finish}, so
    it is definitely assigned.
Field \code{f1} is also definitely assigned, because it is non-final
    so from rule~\userule{Rule10} it has an implicit zero field initializer.
However, field \code{f2} is final so it does not have an implicit field initializer.
Moreover, \code{f2} is only asynchronously assigned,
    and the constructor does not have to wait for this assignment to finish,
    thus violating rule~\userule{Rule13}.
(The exact data-flow analysis to enforce rule~\userule{Rule13} is described in
    \Ref{Section}{Read-write-rules}.)
Rule~\userule{Rule13a} is the same as in Java: a final field is assigned \emph{at most} once
    (and, combined with rule~\userule{Rule13}, we know it is assigned \emph{exactly} once).




\subsection{Distributed programming and Initialization}
\label{Section:Multiple-Places}
X10 programs can be executed on a distributed system with multiple places
    that have no shared memory.
Objects are copied from one place to another when captured by an \code{at}.
Copying is done by first serializing the object into a buffer,
    sending the buffer to the other place, and then de-serializing the buffer at the other place.
As in Java, one can write custom serialization code in X10 by implementing the \code{CustomSerialization} interface,
    and defining the method \code{serialize():SerialData} and the constructor \code{this(data:SerialData)}.


\Ref{Figure}{Asynchronously-init}b shows a common pitfall
    where a raw \this escapes to another place,
    and the field assignment would have been done on a copy of \this.
We wish to de-serialize only cooked objects,
    and therefore rule~\userule{Rule14} prohibits \this to be captured by an \code{at}.
Consequently, we also report that field \code{f} was not definitely assigned.


%\begin{lstlisting}
%class A {
%  var i:Int;
%  val distArray = DistArray.make( ..., (Point)=>this.i); // "this" is serialized to another place before it is cooked
%}
%\end{lstlisting}

\removeGlobalRef{
\subsection{Global references}
\label{Section:Global-references}
A distributed data-structures is dispersed over multiple places,
    and it is convenient to have pointers from one place to an object in another place.
These cross-places pointers are called \emph{global references}.
A global reference has two fields: \code{object} that points to some object,
    and \code{home} which is the place where the global reference was created.
When a global reference is serialized, we serialize its \code{home} and the value of the \emph{pointer} to the \code{object}
    (we do not serialize the \code{object}).
%Phrased differently, serializing an object will recursively serialize all its fields;
%    the recursion ends when there are no fields or with global references.
%Retrieving the object is only allowed at place \code{home}.
%    i.e., the apply method returns the root and is guarded by \code{home==here}.
For example, suppose that \code{o} is some object.
Then, when a box pointing to \code{o} is serialized, then \code{o} is recursively serialized.
However, when a global reference pointing to \code{o} is serialized, then only the pointer to \code{o} is serialized (not \code{o} itself).
%  assert r()==o;
%def copyExample(o:Any, p:Place) {
%\begin{lstlisting}
%  val box = new Box(o);
%  at (here.next()) { // copies box and o
%    val x = box;
%  }
%  val r = new GlobalRef(o);
%  at (here.next()) { // copies r but not o
%    val x = r;
%  }
%\end{lstlisting}

% No room to talk about custom serialization:
% Places require serialization and deserialization (both custom and automatic) across "at".

A \emph{global object} has mutable state in a single place~\code{p}
    and methods that can be called from any place that mutate state in~\code{p}.
The common \emph{global object idiom}
    uses a global reference
    to point to a single mutable object.
\Ref{Figure}{GlobalRef} shows a global counter object
    that has mutable state (\code{count}) in a single place,
    but any place can increment the counter by incrementing \code{count} at that single place,
    which is \code{root.home}.
Note how \code{root()} returns the referent of the global reference.
(The call \code{root()} is guarded by \code{root.home==here}, which is statically verified in this code.)


%  def me() = root();
%}
%class B extends A {
%  def this() {
%    val alias = me(); //err
%  }
%}
%If \code{me()} was prefixed with
%\code{@NonEscaping public final}
%then accessing \code{root} would be an error.
%Cannot use 'root' because a GlobalRef[\ldots](this) cannot be used in a field initializer, constructor, or methods called from a constructor.

\begin{figure}
\vspace*{-2.0ex}
\begin{lstlisting}
class GlobalCounter {
  private val root = new GlobalRef(this);
  transient var count:Int;
  def this() {
    val aliasToThis = this.root(); //err
  }
  def inc() {
    return at(root.home) root().count++;
  }
}
\end{lstlisting}
\vspace*{-2.0ex}
\definerule{TransientRule}
\caption{A global counter example.
    \textbf{Revision of~\userule{Rule3}:}
        A raw \this can only escape to a \code{GlobalRef} constructor in a private field initializer;
            that field cannot be read via a raw \this receiver.
    \myrule{\arabic{TransientRule}}{The type of a \code{transient} field must satisfy \code{haszero}}
    }
\label{Figure:GlobalRef}
\end{figure}
\vspace*{-2.0ex}

Note that a raw \this leaked into the constructor of \code{GlobalRef}
    which is a violation of rule~\userule{Rule3}.
Because this idiom is common in distributed programming,
    we relaxed this rule and allow \this to escape but only into a \code{GlobalRef} object
    with a severe restriction:
    it must happen in a private field initializer that is not read during construction.
For example, \code{root} cannot be read in the constructor
    because it contains an alias to \code{this} that might escape.

As in Java, the \code{transient} keyword marks a field that should not be serialized.
Upon de-serialization, such a field has the zero value.
Therefore, the type of a transient field must have the zero value (rule~\userule{TransientRule}).

We finally note that the global object idiom is error-prone because
    it is easy to forget to use \code{root()} before accessing a mutable field.
There is an RFC that suggests an annotation that will automatically convert a class to a global class
    using this pattern.


}


\subsection{Read and write of fields}
\label{Section:Read-write-rules}


\begin{figure}

\vspace*{-3.0ex}
\subfloat[]{\lstinputlisting[boxpos=t]{ReadWriteOrder1.txt}}
\qquad~\qquad
\subfloat[]{\lstinputlisting[boxpos=t]{ReadWriteOrder2.txt}}
\vspace*{-2.0ex}

\definerule{Rule11}
\definerule{Rule11b}
\caption{Read-Write order for fields.
    We infer for each method three sets:
        (i)~fields it reads (i.e., these fields must be assigned before the method is called),
        (ii)~fields it assigns,
        (iii)~fields it assigns asynchronously.
    The data-flow maintains these three sets before and after each statement;
        \code{\itshape assigned} becomes \code{\itshape asyncAssigned} after an \code{async},
        and \code{\itshape asyncAssigned} becomes \code{\itshape assigned} after a \code{finish}.
    In this example, we omitted empty sets.
    \myrule{\arabic{Rule11}}{A field may be read only if it is definitely-assigned}
    \myrule{\arabic{Rule11b}}{A final field may be written only if it is definitely-unassigned}
    }
\label{Figure:Read-Write-Order}
\end{figure}

We now present a data-flow analysis for guaranteeing
    that a field is read only after it was written,
    and that a final field is assigned exactly once.
Java performs an \emph{intra}-procedural data-flow analysis in \emph{constructors} to calculate
    when a \emph{final} field is definitely-assigned and definitely-unassigned.
In contrast, X10 performs an \emph{inter}-procedural fixed-point data-flow analysis
    in all \emph{non-escaping methods} (and constructors) to calculate
    when {a} field (\emph{both final and non-final}) is
    definitely-assigned, \emph{definitely-asynchronously-assigned}, and definitely-unassigned.
The details are explained using examples (\Ref{Figure}{Read-Write-Order}) by comparison with Java;
    the full analysis is described in X10's language specification.

X10, like Java, allows \emph{writing} to a final field only when it is definitely-\emph{unassigned},
    and it allows \emph{reading} from a final field only when it is definitely-\emph{assigned}.
X10 also has the same read restriction on non-final fields
    (recall that rule~\userule{Rule10} adds a field initializer if the field's type has-zero).


Consider first only final fields.
    They are easier to type-check because they can only be assigned in constructors.
X10 extends Java rules,
    by calculating for each non-escaping method \code{m} the set of final fields it reads,
    and calling \code{m} is legal only if these fields have been definitely assigned.
For example, in class \code{A}, method \code{readA} reads field \code{a}
    and therefore cannot be called before \code{a} is assigned (e.g., \code{\itshape err1}).
Note that Java does not perform this check, and it is legal to call \code{readA}
    which will return the zero value of \code{a}.
X10 also adds the notion of \emph{definitely-asynchronously-assigned}
    which means a field was definitely-assigned within an \code{async}
    (so it cannot be read, e.g., \code{\itshape err2}),
    but after an enclosing \code{finish} it will become definitely-assigned
    (so it can be read).
The flow maintains three sets:
    \code{\itshape reads}, \code{\itshape assigned}, and \code{\itshape asyncAssigned}.
If a method reads an uninitialized field, then we add it to its \code{\itshape reads} set;
    however, if a constructor reads an uninitialized field, then it is an error.
Phrased differently, the \code{\itshape reads} set of a constructor must be empty.

Now consider non-final fields.
    They can be assigned and read in methods,
        thus requiring a fixed-point algorithm.
For example, consider method \code{writeJ}.
Initially, \code{\itshape reads} is empty,
    while \code{\itshape assigned} and \code{\itshape asyncAssigned} are the entire set of fields.
In the first iteration, we add \code{i} to \code{\itshape reads},
    and when we join the two branches of the \code{if},
    \code{\itshape assigned} is decreased to only \code{j}.
The fixed-point calculation, in every iteration, increases \code{\itshape reads}
    and decreases \code{\itshape assigned} and \code{\itshape asyncAssigned},
    until a fixed-point is reached.

%\Subsection[Virtues]{Virtues and attributes of initialization in X10}
%We assume there is a single \this variable, because all nested classes can be converted to static,
%    as described in \Ref{Section}{Inner}.
%Therefore, initialization in X10 has the following attributes:
%(i)~\this (and its alias \code{super}) is the only accessible raw object in scope (rule~\userule{Rule3}),
%(ii)~only cooked objects cross places (rule~\userule{Rule14}),
%(iii)~only \code{@NoThisAccess} methods can be dynamically dispatched during construction (rule~\userule{Rule5}),
%(iv)~all final field assignments finish by the time the constructor ends (rule~\userule{Rule13}),
%(v)~it is not possible to read an uninitialized field (rule~\userule{Rule11}), and
%(vi)~reading a final field always results in the same value (rule~\userule{Rule11b} combined with attribute~(v)).
